텍스트 파일

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 인코딩
3. 텍스트 파일 형식
4. 텍스트 파일의 장단점
- 4.1. 장점
- 4.2. 단점
5. 텍스트 파일의 활용
6. 텍스트 파일 편집
7. 고급 텍스트 파일 형식
참조

1. 개요

텍스트 파일은 문자를 컴퓨터에서 표현하는 방식인 문자 인코딩을 사용하여 저장되는 파일 형식이다. ASCII, ISO 8859-1, 유니코드(UTF-8, UTF-16) 등 다양한 인코딩 방식이 있으며, 각 방식은 지원하는 문자 범위와 호환성에 차이가 있다. 텍스트 파일은 높은 호환성, 간단한 처리, 데이터 크기 절약 등의 장점을 가지며, 운영체제 및 애플리케이션의 설정 파일로 활용된다. 텍스트 파일은 텍스트 편집기, 코드 편집기, 워드 프로세서 등 다양한 소프트웨어로 편집할 수 있으며, HTML, XML과 같은 고급 텍스트 파일 형식을 통해 문서 구조, 서식, 멀티미디어 데이터를 표현할 수 있다.

더 읽어볼만한 페이지

컴퓨터 데이터 - 헤더 (컴퓨팅)
헤더는 전자 통신, 네트워킹, 파일 형식, 프로그래밍 등 다양한 분야에서 데이터의 전송 및 처리에 필요한 정보를 제공하는 정보의 집합이다.
컴퓨터 데이터 - 데이터 손실
데이터 손실은 절차적 요인, 인적 행위, 시스템 실패, 자연 재해, 범죄 등 다양한 원인으로 발생하며, 금전적 손실과 평판 손상 등 심각한 결과를 초래하므로 강력한 암호, 이중 인증, 정기적인 백업 등의 예방 조치가 중요하다.
파일 포맷 - 바로 가기
바로 가기는 운영체제에서 파일, 폴더, 프로그램, 웹 페이지에 대한 참조를 제공하는 기능 및 파일로, 사용자들이 원본에 빠르게 접근하도록 GUI 환경의 사용성을 향상시킨다.
파일 포맷 - EXE
EXE 파일 형식은 운영 체제에 따라 다양한 종류가 있는 실행 파일의 한 형태로, DOS MZ 실행 파일에서 PE, PE32+까지 발전해 왔으며, 코드, 데이터, 스택을 별도 관리하고 재배치 항목을 통해 실행 환경에 유연하게 대응하는 특징을 가진다.

텍스트 파일 - [IT 관련 정보]에 관한 문서
파일 정보
텍스트 파일 아이콘
일반 정보
파일 확장자	.text, .txt
MIME 형식	text/plain
유형 코드	TEXT
통합 유형	public.plain-text
준수 대상	public.text
매직 넘버	해당 사항 없음
개발자	해당 사항 없음
출시일	해당 사항 없음
최신 버전	해당 사항 없음
최신 버전 출시일	해당 사항 없음
장르	문서 파일 형식, 일반 컨테이너 형식
컨테이너 대상	해당 사항 없음
포함 대상	해당 사항 없음
확장 대상	해당 사항 없음
확장 출처	해당 사항 없음
표준	해당 사항 없음
라이선스	자유
URL	해당 사항 없음

2. 인코딩

텍스트 파일의 내용을 이루는 문자들은 컴퓨터 내부에서 특정 숫자 값으로 변환되어 저장되는데, 이 변환 규칙을 문자 인코딩이라고 한다. 어떤 인코딩 방식을 사용하느냐에 따라 같은 파일이라도 다르게 해석될 수 있으므로, 텍스트 파일을 올바르게 처리하기 위해서는 인코딩에 대한 이해가 필수적이다.

과거에는 영어 중심의 ASCII가 널리 사용되었으나, 비영어권 문자를 표현하는 데 한계가 있었다. 이를 보완하기 위해 ISO 8859-1 등 다양한 확장 인코딩이 등장했지만, 언어별, 시스템별로 다른 인코딩이 사용되어 호환성 문제가 발생했다. 이러한 문제를 해결하기 위해 전 세계의 모든 문자를 포괄하는 유니코드 표준이 제정되었고, 이를 구현하는 인코딩 방식 중 UTF-8은 ASCII 호환성과 효율성 덕분에 현재 웹을 비롯한 많은 환경에서 사실상 표준으로 사용되고 있다.^[10]^[17]

그러나 텍스트 파일 자체에는 사용된 인코딩 정보가 명시적으로 포함되지 않는 경우가 많다. 따라서 파일을 읽는 프로그램은 바이트 오더 마크(BOM)나 내용 분석 등을 통해 인코딩을 추측해야 하며, 잘못된 추측은 문자 깨짐 현상을 유발할 수 있다.

2. 1. ASCII

ASCII는 영어 텍스트 파일에서 가장 보편적으로 사용되는 문자 집합이며, 많은 경우 기본적인 파일 형식으로 간주된다. 과거에는 컴퓨터마다 사용하는 문자 집합이 달라 데이터 교환에 어려움이 있었지만, 표준 규격으로 ASCII가 제정되고 옥텟(1바이트=8비트)을 사용하는 컴퓨터가 주류가 되면서 서로 다른 컴퓨터 간의 문자 데이터 교환이 훨씬 쉬워졌다.

ASCII는 예를 들어 문자 'A'를 16진수 0x41, 'B'를 0x42 등으로 표현한다. 따라서 ASCII로 인코딩된 "ABCD" 문자열은 내부적으로 41424344 (16진수)와 같이 저장된다.

하지만 ASCII는 7비트 문자 코드이기 때문에 기본적인 영문 알파벳, 숫자, 일부 기호만을 표현할 수 있다. 영어 외 유럽 언어에서 사용되는 움라우트나 세디유 같은 발음 구별 기호가 붙은 문자나, 일본어, 중국어처럼 수많은 한자나 가나를 사용하는 언어의 문자는 ASCII로 표현할 수 없다. 이러한 비 ASCII 문자를 표현하기 위해서는 별도의 문자 인코딩 방식이 필요하다. 어떤 인코딩을 사용할지는 시스템의 기본 로케일 설정에 따라 결정되는 경우가 많다. 과거 유럽 언어에서는 ISO 8859-1과 같은 단일 바이트 인코딩이, 아시아 언어에서는 와이드 문자 인코딩이 주로 사용되었다.

이렇게 다양한 확장 인코딩 방식이 존재하면서 국제적인 문자 데이터 교환에 문제가 발생하기도 했다. 이러한 문제를 해결하고 알려진 모든 언어를 하나의 표준으로 표현하기 위해 유니코드 및 ISO/IEC 10646이 제정되었다. 유니코드는 기존의 거의 모든 문자 집합을 포함하는 매우 큰 문자 집합이다.

유니코드를 위한 여러 문자 인코딩 방식 중 가장 널리 사용되는 것은 UTF-8이다. UTF-8의 가장 큰 장점은 ASCII와 하위 호환된다는 점이다. 즉, 모든 ASCII 텍스트 파일은 그 자체로 동일한 의미를 가지는 유효한 UTF-8 텍스트 파일이기도 하다. 이러한 호환성 덕분에 웹사이트를 만드는 데 사용되는 HTML이나 CSS, 그리고 프로그래밍 언어의 소스 파일 등 많은 텍스트 기반 데이터에서 UTF-8 인코딩 채택이 늘고 있다.^[10] 또한 UTF-8은 자동 감지가 비교적 용이하여, 인코딩을 알 수 없는 파일을 열 때 우선 UTF-8로 시도해보는 것이 일반적이다.

현재(2024년 기준) 개인용 컴퓨터나 모바일 기기에서 사용되는 텍스트 파일의 영숫자는 대부분 ASCII 또는 ASCII 호환 인코딩을 사용하므로, 영숫자가 깨지는 경우는 거의 없다. 다만, 백슬래시 문자('\', 코드 0x5C)처럼 ASCII 표준 문자라도 폰트나 환경에 따라 다르게 표시될 수 있는 경우가 있다. 예를 들어 일본어 환경에서는 역사적인 이유로 엔화 기호('¥')로 표시되는 경우가 많다.

한편, 메인프레임과 같은 대형 컴퓨터 시스템에서는 여전히 EBCDIC라는 다른 문자 코드가 사용되는 경우도 있다.

2. 2. ISO 8859-1

ASCII 문자 집합은 영어 텍스트 파일에서 가장 보편적으로 사용되지만, 영어 이외의 언어에서 사용되는 강세 부호나 특수 문자와 같은 비 ASCII 문자를 표현하는 데는 한계가 있다. 이러한 문자를 포함하는 텍스트 파일을 저장하거나 읽을 때는 해당 문자를 올바르게 표현할 수 있는 문자 인코딩 방식이 필요하며, 많은 시스템에서는 사용자의 로캘 설정에 따라 기본 인코딩을 선택한다. ISO 8859-1은 특히 서유럽 언어권에서 널리 사용되는 대표적인 문자 인코딩 방식 중 하나이다.

2. 3. 유니코드 (UTF-8, UTF-16)

유니코드는 알려진 모든 언어의 문자를 표현하기 위한 공통 표준을 만들려는 시도로, 전 세계의 모든 문자를 통일적으로 처리하는 것을 목표로 하는 국제 표준 부호화 문자 집합 규격이다.^[10]^[17] 기존의 ASCII나 ISO 8859-1과 같은 문자 인코딩들은 표현할 수 있는 문자가 제한적이어서 특정 언어권에서만 주로 사용되었으나, 유니코드는 이러한 한계를 극복하고자 등장했다. 대부분의 알려진 문자 집합들은 유니코드 문자 집합의 하위 집합에 속한다.

유니코드에는 여러 문자 인코딩 방식이 존재하는데, 그중 가장 흔하게 사용되는 것은 UTF-8이다. UTF-8은 ASCII와 하위 호환된다는 큰 장점이 있어, 모든 ASCII 텍스트 파일은 별도의 변환 없이 UTF-8 텍스트 파일로도 간주될 수 있다. 또한 UTF-8은 자동 감지가 용이하여, 텍스트 편집기 등의 소프트웨어가 파일 인코딩을 식별할 때 우선적으로 시도하는 방식이기도 하다. 이러한 장점으로 웹사이트(HTML, CSS)나 프로그래밍 언어의 소스 파일 등 호환성이 중요한 분야에서 사실상 표준 인코딩 방식으로 자리 잡았다. 웹사이트에서의 UTF-8 사용률은 2012년에 60%를 넘었고^[17], 2017년에는 90%를 넘어섰다^[10]. UTF-16 역시 실용적으로 많이 사용되는 유니코드 인코딩 방식 중 하나이다.

유니코드의 보급으로 여러 언어의 문자가 섞인 문서를 쉽게 작성할 수 있게 되었고, 영문자 외 문자를 처리할 때의 호환성도 크게 향상되었다.

하지만 유니코드에도 문제점은 존재한다. 여전히 많은 오래된 시스템이나 웹사이트에서는 기존의 구형 인코딩 방식을 사용하고 있어 완전한 통일은 이루어지지 않았으며, 오히려 UTF-8, UTF-16 등 다양한 인코딩 방식의 등장으로 문자 깨짐과 같은 혼란이 가중되는 측면도 있다. 특히 한글, 한자, 가나 등 복잡한 문자의 경우, 서로게이트 페어, 결합 문자, 서기소 클러스터, 이모지 등을 올바르게 표시하고 편집하기 위해서는 최신 기술을 지원하는 프로그램과 폰트가 필요하다. 또한 유니코드 규격 자체도 계속 업데이트되므로, 구버전 시스템에서는 새로운 규격에 추가된 문자를 제대로 표시하지 못하는 문제도 발생한다.

특히 유니코드 설계상의 큰 문제점 중 하나로 CJK 통합 한자가 지적된다. 이는 문자 세트 크기를 줄이기 위해 한국어, 중국어, 일본어에서 사용되는 한자 중 모양이 유사한 것들을 언어 구분 없이 하나의 코드 포인트로 통합해 버린 것이다. 이로 인해 각 언어의 미묘한 자형 차이를 반영하지 못하게 되었고, 결과적으로 단일 폰트만으로는 여러 언어의 한자를 정확하게 표현하기 어렵게 만드는 설계상의 오류로 평가받는다. 웹 페이지 등에서 이를 제대로 표시하려면 문서의 언어를 명시적으로 지정하고 해당 언어에 맞는 문자 모양을 가진 폰트를 사용해야 한다^[18].

2. 4. 한국어 인코딩 (EUC-KR, CP949)

ASCII 문자 집합은 기본적인 영문자만 표현할 수 있어, 한글과 같은 비영어권 문자를 나타내기에는 한계가 있었다. 과거에는 컴퓨터 시스템의 로케일 설정에 따라 다양한 문자 인코딩 방식이 사용되었다. 한국어 환경에서는 주로 EUC-KR 또는 이를 확장하여 더 많은 한글을 표현할 수 있게 만든 CP949(MS949, Windows-949) 인코딩이 널리 쓰였다.

하지만 EUC-KR, CP949를 포함한 과거의 여러 인코딩 방식들은 각자 표현할 수 있는 문자가 제한적이었고, 시스템이나 환경이 다르면 문자 깨짐 현상이 발생하는 등 호환성 문제가 빈번했다. 이는 비단 한국어 환경만의 문제는 아니었으며, 예를 들어 일본어 환경에서도 Shift JIS, EUC-JP 등 여러 인코딩 방식이 혼재하고 Microsoft 코드 페이지 932와 같이 독자적인 확장 규격까지 등장하면서 데이터 교환에 어려움이 있었다.

이러한 문제를 해결하고 전 세계의 모든 언어 문자를 통일된 방식으로 처리하기 위해 유니코드 표준이 제정되었다. 유니코드의 여러 인코딩 방식 중 특히 UTF-8은 기존 ASCII와 호환되면서도 모든 유니코드 문자를 표현할 수 있다는 장점 덕분에 빠르게 확산되었다. 웹사이트^[10]^[17]나 프로그래밍 언어의 소스 파일 등 다양한 분야에서 UTF-8 사용이 표준처럼 자리 잡게 되면서, 현재 한국어 텍스트 파일 역시 과거의 EUC-KR이나 CP949 대신 UTF-8로 작성되는 경우가 대부분이다.

3. 텍스트 파일 형식

수많은 운영 체제에서 텍스트 파일은 서식(굵게 또는 기울임 등)이 없는 플레인 텍스트 내용만 허용하는 파일 형식을 가리킨다. 이러한 파일들은 텍스트 터미널이나 단순 문서 편집기를 통해 확인하고 편집할 수 있다. 텍스트 파일들은 보통 MIME 타입으로 `text/plain`을 가지며, 사용된 문자 인코딩을 가리키는 추가 정보가 포함되기도 한다.

텍스트 파일은 단순성 때문에 정보 저장에 널리 사용된다. 바이트 순서, 패딩 바이트, 머신 워드 내 바이트 수 차이 등 다른 파일 형식에서 발생할 수 있는 몇 가지 문제를 피할 수 있다는 장점이 있다. 또한, 텍스트 파일에 데이터 손상이 발생하더라도 나머지 내용을 복구하고 계속 처리하기가 비교적 쉽다. 그러나 텍스트 파일은 일반적으로 엔트로피가 낮아, 정보를 저장하는 데 필요한 것보다 더 많은 저장 공간을 차지하는 경향이 있다는 단점이 있다.

단순 텍스트 파일은 해당 문자 집합에 대한 지식 외에는 해석에 필요한 추가적인 메타데이터가 거의 필요하지 않다. 내용이 전혀 없는 0 바이트 파일 형태일 수도 있다.

텍스트 파일의 내부 구조는 문자 코드로 표시되는 데이터와 제어 문자로 구성된다. 제어 문자 중 하나인 개행(줄 바꿈)은 텍스트 파일 내에서 데이터의 구분을 나타내는 중요한 역할을 한다. 한 행은 개행으로 구분된 하나의 레코드로 간주될 수 있다. 바이너리 파일과 달리 파일 중간에 널 문자(값 0)가 나타나지 않는 것이 일반적이다. 제어 문자에는 줄 바꿈 외에도 탭(수평 탭) 등이 있으며, 각각 고유한 문자 코드가 할당되어 있다. (예: ASCII에서 LF는 `0x0A`, 수평 탭은 `0x09`)

역사적으로 CP/M 운영 체제에서는 파일 크기를 정확히 관리하지 않았기 때문에, 텍스트 파일의 끝을 명확히 하기 위해 EOF (파일 끝 표시 문자, ASCII의 SUB 문자 `0x1A`)를 파일 내용 마지막에 추가하는 관행이 있었다. MS-DOS에서도 CP/M과의 호환성을 위해 이 방식이 사용되기도 했다.

텍스트 파일은 여러 기준으로 분류될 수 있다.

각 행(레코드)의 길이가 고정적인지 가변적인지 여부: 메인프레임 환경에서는 고정 길이 레코드가 일반적이었으나, 유닉스나 PC 환경에서는 가변 길이 행이 주로 사용된다.
문자 인코딩 방식
줄 바꿈 문자

특히, 텍스트 파일에서 줄 바꿈을 나타내는 코드는 컴퓨터 환경(운영 체제)에 따라 다르며, 이는 과거 파일 호환성 문제를 일으키는 주요 원인이었다.

MS-DOS와 윈도우에서는 캐리지 리턴(CR, `\r`, `0x0D`)과 라인 피드(LF, `\n`, `0x0A`) 두 문자를 조합한 CR+LF (`\r\n`)를 사용한다.^[19]
유닉스 계열 운영 체제에서는 LF (`\n`) 하나만을 사용한다. POSIX 표준은 텍스트 파일을 0개 이상의 줄로 구성된 문자를 포함하는 파일로 정의하며, 각 줄은 종단 새줄 문자(보통 LF)로 끝난다고 명시한다.^[23]^[24] macOS 역시 유닉스 기반이므로 LF를 사용한다.
Classic Mac OS (버전 9까지)에서는 CR (`\r`)을 사용했다.

이러한 운영체제 간 줄 바꿈 코드의 차이 때문에 과거에는 한 운영체제에서 만든 텍스트 파일을 다른 운영체제에서 열었을 때 줄 바꿈이 제대로 표시되지 않거나 이상한 문자가 보이는 문제가 발생하기도 했다.^[19] 하지만 오늘날 대부분의 텍스트 편집기는 다양한 줄 바꿈 코드를 자동으로 인식하고 처리할 수 있어 이러한 문제는 크게 줄어들었다. 그럼에도 불구하고, 하나의 파일 내에서는 줄 바꿈 코드를 통일하는 것이 예기치 않은 문제를 방지하는 데 도움이 된다.

3. 1. 윈도우 텍스트 파일

MS-DOS와 윈도우는 동일한 텍스트 파일 형식을 사용하며, 각 텍스트 줄은 캐리지 리턴(CR)과 라인 피드(LF)라는 두 문자의 조합(CR+LF, `\r\n`)으로 구분된다. 텍스트의 마지막 줄이 CR+LF로 끝나지 않는 경우도 흔하며, 메모장과 같은 많은 텍스트 편집기는 마지막 줄에 자동으로 CR+LF를 삽입하지 않기도 한다.

윈도우 운영 체제에서는 일반적으로 파일 확장자가 `.txt`인 파일을 텍스트 파일로 간주한다. 하지만 특정 목적을 가진 텍스트 파일은 다른 확장자를 사용하기도 한다. 예를 들어, 컴퓨터 프로그램의 소스 코드는 대개 해당 프로그래밍 언어를 나타내는 확장자를 가진 텍스트 파일에 저장된다.

대부분의 윈도우 텍스트 파일은 ANSI, OEM, 유니코드 또는 UTF-8 인코딩 중 하나를 사용한다. 윈도우에서 "ANSI 인코딩"이라고 부르는 것은 보통 단일 바이트 ISO/IEC 8859 인코딩(즉, 시스템 코드 페이지)을 의미하며, 이는 유니코드가 보편화되기 전에 기본 시스템 로케일로 사용되었다. 다만, 중국어, 일본어, 한국어처럼 더블 바이트 문자 집합이 필요한 로케일은 예외이다. 반면, DOS 코드 페이지라고도 불리는 OEM 인코딩은 원래 IBM PC 텍스트 모드 디스플레이 시스템을 위해 IBM에서 정의한 것으로, DOS 응용 프로그램에서 자주 사용되는 그래픽 문자와 선 그리기 문자를 포함한다. "유니코드"로 인코딩된 윈도우 텍스트 파일은 UTF-16 형식의 텍스트를 담고 있으며, 보통 파일 시작 부분에 바이트 순서 표시(BOM)를 넣어 파일 내용의 엔디안(endianness)을 나타낸다. UTF-8은 엔디안 문제의 영향을 받지 않지만, 메모장과 같은 많은 윈도우 프로그램은 UTF-8 인코딩 파일의 내용 앞에 BOM을 추가하여^[2] 다른 8비트 인코딩과 구별하기도 한다.^[3]

텍스트 파일에서 줄 바꿈을 나타내는 코드는 운영체제마다 달라 호환성 문제를 일으키는 원인이 되기도 한다. 줄 바꿈은 주로 제어 문자 LF(Line Feed, 0x0A)와 CR(Carriage Return, 0x0D)로 표시된다.

운영체제	줄 바꿈 코드
MS-DOS, 윈도우	CR+LF (`\r\n`)
유닉스(리눅스, macOS 포함)	LF (`\n`)
Classic Mac OS (버전 9까지)	CR (`\r`)

MS-DOS는 CP/M과의 호환성을 위해 CR+LF 방식을 채택했고, 윈도우도 이를 따랐다.^[19] Microsoft Visual C++의 표준 C 라이브러리에서 `'fopen()'` 함수를 텍스트 모드로 사용하여 파일을 열면, 파일을 읽을 때 CR+LF를 LF로 자동 변환하고, 쓸 때는 LF를 CR+LF로 자동 변환한다.^[20] 이러한 자동 변환을 원하지 않는다면 바이너리 모드를 사용해야 한다.

과거에는 윈도우에서 만든 텍스트 파일(CR+LF)을 유닉스/리눅스에서 열면 줄 끝에 불필요한 문자(^M 등)가 보이거나, 반대로 유닉스/리눅스에서 만든 파일(LF)을 윈도우 메모장에서 열면 줄 바꿈이 제대로 표시되지 않고 한 줄로 이어져 보이는 문제가 있었다.^[19] 하지만 최근의 텍스트 편집기들은 대부분 CR+LF와 LF 방식을 모두 지원하여 이러한 문제를 해결한다. 편집기에 따라 줄 바꿈 코드가 혼재된 파일을 그대로 처리하거나, 저장 시 특정 방식으로 통일하기도 한다. 다만, 줄 바꿈 코드의 혼재는 여전히 문제를 일으킬 수 있으므로, 하나의 파일 안에서는 한 가지 방식으로 통일하는 것이 좋다. Microsoft Visual Studio의 코드 편집기는 소스 파일을 열 때 줄 바꿈 코드의 불일치를 감지하면 사용자에게 통일할 것인지 묻는다.

한편, 전자 메일 본문에서는 RFC 2822 표준에 따라 줄 바꿈에 CR+LF를 사용하도록 규정되어 있다.^[21]

3. 2. 유닉스/리눅스 텍스트 파일

유닉스 계열 운영 체제에서 텍스트 파일은 POSIX 표준에 따라 정의된다. POSIX는 텍스트 파일을 0개 이상의 줄(line)로 구성된 문자를 포함하는 파일로 정의하며,^[23] 각 줄은 0개 이상의 줄 바꿈 문자가 아닌 문자와 마지막에 오는 줄 바꿈 문자(newline character)로 이루어진다.^[24]

유닉스 및 리눅스 계열 운영 체제에서는 이 줄 바꿈 문자로 라인 피드(Line Feed, LF), 즉 `\n` (ASCII 코드 0x0A) 문자 하나만을 사용한다.^[5] 이는 MS-DOS나 Windows 환경에서 줄 바꿈을 위해 사용하는 캐리지 리턴(Carriage Return, CR)과 라인 피드(LF)의 조합(CR+LF, 0x0D 0x0A)이나, Classic Mac OS (버전 9까지)에서 사용하던 CR(0x0D)과는 다른 방식이다.^[19] 유닉스 기반으로 재설계된 macOS 역시 LF를 표준 줄 바꿈 문자로 사용한다.

또한 POSIX는 '''인쇄 가능 파일'''(printable file)을 지역 규칙에 따라 인쇄 가능한 문자, 공백(space), 또는 백스페이스(backspace) 문자를 포함하는 텍스트 파일로 정의한다. 여기에는 인쇄 불가능한 대부분의 제어 문자가 제외된다.^[6]

이러한 운영체제 간 줄 바꿈 코드의 차이 때문에 과거에는 Windows에서 생성한 텍스트 파일(CR+LF)을 유닉스/리눅스에서 열면 줄 끝에 불필요한 문자(CR)가 보이거나, 반대로 유닉스/리눅스에서 생성한 파일(LF)을 Windows의 일부 오래된 프로그램(예: 메모장)에서 열면 줄 바꿈이 인식되지 않고 모든 내용이 한 줄로 이어져 보이는 문제가 발생하기도 했다.^[19] 하지만 최근의 많은 텍스트 편집기는 CR+LF, LF 등 다양한 줄 바꿈 코드를 자동으로 인식하고 처리할 수 있어 운영체제 간 파일 교환 시 불편함이 크게 줄었다.

3. 3. macOS 텍스트 파일

macOS가 등장하기 전의 클래식 Mac OS 시스템에서는 파일의 리소스 포크가 파일 형식을 "TEXT"로 지정하면 해당 파일의 내용(데이터 포크)을 텍스트 파일로 간주했다.^[7] 클래식 Mac OS 텍스트 파일의 각 줄은 캐리지 리턴 (CR) 문자로 끝났다.^[8]

유닉스 계열 운영 체제인 macOS는 유닉스와 동일한 텍스트 파일 형식을 사용하며,^[8] 줄 바꿈 문자로는 라인 피드 (LF)를 사용한다. 이는 클래식 Mac OS에서 사용하던 CR 방식과는 다르다. macOS에서 텍스트 파일을 나타내는 통합 형식 식별자 (UTI)는 "public.plain-text"이며, 인코딩 방식이나 호환성에 따라 다음과 같은 더 구체적인 UTI가 사용되기도 한다.^[7]

'''UTF-8 인코딩 텍스트:''' "public.utf8-plain-text"
'''UTF-16 인코딩 텍스트:''' "public.utf16-external-plain-text", "public.utf16-plain-text"
'''클래식 Mac OS 텍스트 파일:''' "com.apple.traditional-mac-plain-text"

4. 텍스트 파일의 장단점

텍스트 파일은 그 단순성 덕분에 정보 저장에 널리 사용된다. 이러한 단순함은 바이트 순서 문제나 머신 워드 내 바이트 수 차이와 같은 복잡한 문제를 피할 수 있게 해주며, 데이터 손상 시에도 내용 복구가 비교적 용이하다는 장점을 제공한다.

그러나 텍스트 파일은 일반적으로 정보 저장에 필요한 최소한의 공간보다 더 많은 저장 공간을 차지하는 경향이 있다(낮은 엔트로피). 또한, 플레인 텍스트 외에 복잡한 서식이나 멀티미디어 데이터를 직접 포함하기 어렵고, 사용된 문자 인코딩 방식에 따라 다른 시스템 환경에서 문자 깨짐이 발생할 수 있다는 단점도 가지고 있다.

4. 1. 장점

텍스트 파일은 구조가 단순하기 때문에 여러 장점을 가진다.

높은 호환성: 다양한 운영 체제와 프로그램 환경 사이에서 비교적 높은 호환성을 보인다. 특히 ASCII 범위 내의 문자 데이터만 사용한다면 호환성이 더욱 높아진다.
간단한 처리: 구조가 단순하여 텍스트 파일을 지원하는 프로그램을 비교적 쉽게 만들 수 있다.
가독성: 텍스트 터미널이나 단순 문서 편집기 등을 이용해 사람이 직접 내용을 확인하고 편집하기 용이하다.
데이터 복구 용이성: 파일 일부에 데이터 손상이 발생하더라도, 손상되지 않은 나머지 내용을 복구하고 계속 처리하기가 상대적으로 쉽다.
엔디안 독립성: 데이터를 8비트(1바이트) 단위로 인코딩하는 경우, 엔디안(바이트 순서) 문제에 영향을 받지 않는다.
내부 표현 비의존성: 숫자를 10진수 텍스트로 표현하면 컴퓨터 내부의 숫자 표현 방식(예: 2의 보수나 IEEE 754 형식)에 의존하지 않으므로, 서로 다른 시스템 간에 숫자 정보를 교환하기 쉽다.
데이터 크기 절약 (경우에 따라): 숫자를 가변 길이 텍스트로 표현할 때, '0'이나 '1'과 같이 자릿수가 적은 숫자는 8비트 인코딩 시 1바이트만 차지한다. 이는 32비트나 64비트 같은 고정 길이 이진 표현보다 저장 공간을 절약할 수 있는 경우가 된다.
메타데이터 불필요: 단순 텍스트 파일은 내용을 해석하기 위해 별도의 메타데이터가 거의 필요 없다. 사용된 문자 집합에 대한 정보 정도만 알면 되는 경우가 많다.

이러한 장점들 때문에 운영 체제나 여러 응용 소프트웨어의 설정 파일 형식으로 텍스트 파일이 자주 사용된다.

4. 2. 단점

텍스트 파일은 단순하다는 장점이 있지만, 몇 가지 단점도 가지고 있다.

우선, 텍스트 파일은 기본적으로 플레인 텍스트만 저장할 수 있으므로, 글꼴, 크기, 색상, '''굵게'''나 ''기울임''과 같은 서식 정보를 직접 포함할 수 없다. 마찬가지로 이미지, 음성, 동영상과 같은 멀티미디어 데이터도 직접 저장하기 어렵다. 이러한 데이터를 텍스트 파일에 담으려면 별도의 마크업 언어를 사용하거나 Base64와 같은 방식으로 문자열 인코딩을 해야 하는데, 이는 바이너리 파일에 비해 파일 크기를 비대하게 만들 수 있다^[12].

또한, 텍스트 파일은 정보를 표현하는 데 필요한 최소한의 공간보다 더 많은 저장 공간을 차지하는 경향이 있다. 이는 텍스트 파일이 일반적으로 낮은 엔트로피를 갖기 때문이다. 특히 숫자나 특정 데이터 구조를 텍스트로 표현할 때 비효율적일 수 있다. 예를 들어, 바이너리 데이터를 16진수 텍스트로 표현하면 원래 데이터보다 2배의 저장 공간이 필요하며, 이는 파일 크기 증가와 처리 시간 지연으로 이어질 수 있다.

가장 큰 문제 중 하나는 문자 인코딩의 비호환성이다. ASCII 문자로만 이루어진 파일은 비교적 호환성이 높지만, 한글, 한자, 일본어 가나 등 비영어권 문자가 포함될 경우 문제가 발생하기 쉽다. 과거에는 Shift JIS, EUC-JP, ISO-2022-JP 등 다양한 인코딩 방식이 사용되었고, 각 환경에 맞는 인코딩이 아니면 문자 깨짐 현상이 발생했다. 유니코드, 특히 UTF-8의 보급으로 이러한 문제가 많이 개선되었지만^[17]^[10], 여전히 오래된 시스템과의 호환성 문제나 CJK 통합 한자와 같이 여러 언어의 비슷한 문자를 통합하면서 발생하는 문제^[18], 또는 서로게이트 페어, 결합 문자 등을 제대로 처리하지 못하는 문제 등이 남아있다. 더욱이 텍스트 파일 자체에는 어떤 인코딩이 사용되었는지 명시하는 표준적인 방법이 없어서, 파일을 열 때 인코딩 방식을 추측하거나 사용자가 직접 지정해야 하는 불편함이 있다.

5. 텍스트 파일의 활용

텍스트 파일은 단순성 때문에 정보 저장에 일반적으로 사용된다. 이는 운영 체제나 응용 프로그램의 설정을 기록하는 설정 파일, 시스템이나 프로그램의 작동 기록을 남기는 로그 파일, 또는 간단한 데이터를 표 형태로 저장하는 CSV 파일 등 다양한 형태로 활용될 수 있다. 텍스트 파일은 바이트 순서, 패딩 바이트 또는 머신 워드 내 바이트 수의 차이와 같은 다른 파일 형식에서 발생할 수 있는 복잡한 문제를 피할 수 있다는 장점이 있다. 또한, 파일 일부에 데이터 손상이 발생하더라도 손상되지 않은 나머지 내용을 복구하고 계속 처리하기가 상대적으로 용이하다.

프로그래밍 분야에서도 소스 코드를 작성하고 관리하는 데 텍스트 파일이 기본적으로 사용된다. 웹사이트 개발에 사용되는 HTML 및 CSS 파일과 마찬가지로, 다양한 시스템 간 호환성을 높이기 위해 프로그래밍 언어의 소스 파일 역시 UTF-8 인코딩을 사용하는 경우가 늘고 있다.^[10]

6. 텍스트 파일 편집

텍스트 파일은 워드나 이치타로, 엑셀 등 다양한 소프트웨어에서 지원한다. 파일을 저장할 때 텍스트 파일 형식을 지정하면 이러한 프로그램을 텍스트 파일 생성 및 편집 도구로 사용할 수 있다. 그러나 텍스트 파일을 편집할 때는 해당 소프트웨어의 다양한 기능을 대부분 사용할 수 없으며, 오히려 텍스트 편집에 불편한 경우도 많다.

텍스트 편집기는 텍스트 파일의 생성, 편집, 열람에 특화된 소프트웨어로, 가볍고 빠르게 작동하며 텍스트 읽기 및 쓰기에 편리한 기능을 갖춘 경우가 많다. 프로그래밍 언어를 포함한 컴퓨터 언어 전반의 소스 파일 편집에 특화된 텍스트 편집기는 코드 편집기라고 불린다. 통합 개발 환경(IDE)에 탑재된 코드 편집기는 언어의 키워드 (예약어) 등에 따라 텍스트 색상을 구분하거나 코드 입력을 보조하는 등 고도화된 기능을 갖추고 있으며, 디버거와의 연동도 가능하다.

7. 고급 텍스트 파일 형식

플레인 텍스트 파일은 서식 정보 없이 문자 데이터만 포함하는 기본적인 형태이지만, 이러한 한계를 넘어 부가 정보나 멀티미디어 데이터를 표현하기 위해 더 발전된 텍스트 기반 파일 형식들이 개발되었다. 대표적인 예로 LaTeX, HTML, XML 등이 있다.

이러한 형식들은 마크업 언어라고 불리며, 텍스트 내에 특별한 의미를 가진 태그(tag)를 사용하여 문서의 구조, 서식, 또는 멀티미디어 데이터에 대한 참조 등을 표시한다. 예를 들어, HTML이나 XML 파일은 일반적인 문서 편집기로 열면 태그가 포함된 텍스트 내용이 그대로 보이지만, 해당 파일을 지원하는 웹 브라우저 등으로 열면 태그의 지시에 따라 서식이 적용되거나 이미지가 표시되는 등 의도된 결과가 나타난다.

특히 XML은 다양한 분야에서 활용된다. .NET 환경에서는 XML 텍스트를 이용해 객체를 저장하고 불러오는 직렬화 및 역직렬화 기능을 지원한다^[13]. 이를 통해 복잡한 데이터를 텍스트 파일 형태로 다룰 수 있다. 또한, .NET Framework 2.0 버전부터는 애플리케이션의 설정을 XML 파일로 쉽게 관리할 수 있는 기능도 제공된다^[14]. 과거에는 애플리케이션 설정을 저장하는 데 INI 파일 형식이 주로 사용되었으나, XML이 MSXML이나 Java 표준 라이브러리 등에서 널리 지원되면서 유연성과 기능성이 더 뛰어난 XML을 설정 파일로 채택하는 경우가 많아졌다.

한편, XML보다 더 가볍고 간결한 데이터 표현 방식으로 JSON 형식이 주목받고 있다. JSON은 특히 웹 애플리케이션 간의 데이터 교환에 널리 사용되며, 설정 파일 등 다양한 용도로 활용 범위가 넓어지고 있다. 예를 들어, Visual Studio Code 편집기는 표준 JSON 형식에 주석 기능을 추가한 JSONC(JSON with Comments) 형식의 텍스트 파일(예: settings.json)을 사용하여 사용자 설정을 관리한다^[15]^[16].

참조

_[1] 서적 Computer Science Illuminated https://archive.org/[...] Jones and Bartlett
_[2] 웹사이트 Using Byte Order Marks https://docs.microso[...] Microsoft 2021-01-07
_[3] 웹사이트 FAQ – UTF-8, UTF-16, UTF-32 & BOM https://www.unicode.[...] The Unicode Consortium 2015-12-18
_[4] 웹사이트 3.403 Text File http://pubs.opengrou[...] IEEE Computer Society 2019-03-01
_[5] 웹사이트 3.206 Line http://pubs.opengrou[...] IEEE Computer Society 2015-12-15
_[6] 웹사이트 3.284 Printable File http://pubs.opengrou[...] IEEE Computer Society 2015-12-15
_[7] 웹사이트 System-Declared Uniform Type Identifiers https://developer.ap[...] Apple Inc. 2016-09-12
_[8] 웹사이트 Designing Scripts for Cross-Platform Deployment https://developer.ap[...] Apple Inc. 2016-09-12
_[9] 웹사이트 用語集: Null 文字 https://www.emeditor[...]
_[10] 뉴스 Webサイトの文字コーディング、90%がUTF-8利用 - Shift JISは0.9% | TECH+（テックプラス） https://news.mynavi.[...]
_[11] 웹사이트 Word文書に載っている画像をまとめて取り出す方法！ ExcelやPowerPointでも使える裏技 - 残業を減らす！Officeテクニック - 窓の杜 https://forest.watch[...]
_[12] 웹사이트 バイナリー・データの処理 - IBM Documentation https://www.ibm.com/[...]
_[13] 웹사이트 XML シリアル化の詳細 | Microsoft Learn https://learn.micros[...]
_[14] 웹사이트 ConfigurationManager.AppSettings Property (System.Configuration) | Microsoft Learn https://learn.micros[...]
_[15] 웹사이트 Visual Studio Code User and Workspace Settings https://code.visuals[...]
_[16] 웹사이트 JSON editing in Visual Studio Code https://code.visuals[...] 2023-10-07
_[17] 뉴스 UTF-8の普及率が60%を突破、ASCIIも含めれば80%に近づく | TECH+（テックプラス） https://news.mynavi.[...]
_[18] 웹사이트 Your code displays Japanese wrong | Your Code Displays Japanese Wrong https://heistak.gith[...]
_[19] 웹사이트 ASCII.jp：Windowsにおける改行文字の扱い (1/2) https://ascii.jp/ele[...]
_[20] 웹사이트 fopen, _wfopen | Microsoft Learn https://learn.micros[...]
_[21] 웹사이트 改行について - めぇるの部屋 http://www.t-net.ne.[...]
_[22] 서적 Computer Science Illuminated Jones and Bartlett
_[23] 웹인용 3.397 Text File http://pubs.opengrou[...] IEEE Computer Society 2015-12-15
_[24] 웹인용 3.206 Line http://pubs.opengrou[...] IEEE Computer Society 2015-12-15

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com